home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 700 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.9 KB
  1. Date: Tue, 05 Jul 94 23:32:00 +0200
  2. Message-Id: <2e19eb44@daggskim.ct.se>
  3. From: bo.leuf@daggskim.ct.se (Bo Leuf)
  4. Subject: Re: thoughts and conjectures
  5. To: gem-list@world.std.com
  6. Precedence: bulk
  7.  
  8.  
  9.  > From Annius.Groenink@cwi.nl (Annius Groenink)
  10.  
  11.  > [...]
  12.  > I agree with Rick  Flashman that the right  approach to mouse clicks
  13.  > in background windows when MTOS or WINX are NOT installed is to require
  14.  > the user to hold the right mouse button and use left clicks.
  15.  
  16. This is a good approach, unless the OS (or app) supports a "floating" window
  17. for the toolbox. Normal behaviour on left-click-background should remain as TOP
  18. window.
  19.  
  20. > From Timothy Miller <millert@undergrad.csee.usf.edu>
  21.  
  22. > One recurring theme I see coming from some of you is that you seem to
  23. > want to make drastic changes to the way the GEM interface operates on a
  24. > fundamental level.  Putting dialogs into windows is great, IMO.  But
  25. > making other changes like (For things other than tool boxes) not topping
  26. > windows when they're clicked in not only confuse and frustrate people
  27. > (myself included), but they often make simple things (like topping
  28. > windows when you WANT to) difficult.
  29. > [...GEM GUI...]
  30. > Adding good features is one thing, but let's not go crazy with this.
  31. > Demanding that people start going against the basic design of the
  32. > operating system is not reasonable... at least not until these features
  33. > become part of the real OS.
  34.  
  35. Well said! I find myself at times losing sight of what the purpose of this list
  36. is and find the occasional restatement by "Ogal" of his original aim with the
  37. proposal for keyboad shortcuts needful. I'm not happy about the insistence that
  38. we all follow the established German standard, but hey, I can live with that
  39. since the differences are minimal. Especially with a global (editable) SYS
  40. file, which could be varied for different language groups (say all US
  41. developers want to use ^W instead of ^U: they modify their SYS file and German
  42. programs supporting this will show ^W, and Germans using US programs will find
  43. ^U in their menus).
  44.  
  45. The main thrust here must be to gain a broad acceptance of compliance for this
  46. sort of global shortcut. Once the compliance is there, it does not matter that
  47. user A wants different shortcuts from user B, the point is that _all_ compliant
  48. programs show the _same_ shortcuts consistently on _any_ user's system,
  49. referring to that user's SYS-file. I don't really _care_ if the default SYS is
  50. the German one or not, as long as programs handle this in a consistant manner
  51. and let _me_ redefine anything which collides or is awkward for _me_ on _my_
  52. system.
  53.  
  54.  > From Annius.Groenink@cwi.nl (Annius Groenink)
  55.  > -----
  56.  > 
  57.  > CONJECTURE.  The only  Control +  ASCII key combinations  and Control
  58.  > + shift + ASCII key combinations which  are the same on all
  59.  > international keyboards are letters.
  60.  
  61. Slight reconjecture: ... which are the same [character] are English (ASCII-7)
  62. A-Z (That keyboard position might vary for some letters is not a problem here,
  63. e.g. A, Z, Y, Q).
  64.  
  65. It must be remembered for shortcut use that shifted number and shifted symbol
  66. keys have different assignments on different language keyboards.
  67.  
  68. > From Mark.Baker@mettav.exnet.com (Mark Baker)
  69. > > Where do you get the UP arrow from without pressing SHIFT? I 
  70. > > thought it was SHIFT-=.
  71. > It's shift-6 on English and I guess American keyboards. The unshifted 
  72. > chars on a normal UK keyboard are \,./;'#[]-=` The only ones on both 
  73. > these lists are ',.- which is fairly restrictive.
  74.  
  75. Exactly. So they should be avoided.
  76.  
  77. [...]
  78. > From g02o@zfn.uni-bremen.de (Mark-Oliver Wolter)
  79.  
  80. > >If you put your dialog in a window, the "closer" should be the same as
  81. > >CANCEL or ABORT.  The "mover" should allow moving the dialog. [...]
  82. > ...or qed, which is a very good example. Closing the window doesn't delete
  83. > anything, and when you double-click the icon of that text, you'll be at > the
  84. same cursor position as when closing.
  85.  
  86. But this is "minimize" or "iconify" window, not "close". Not same.
  87.  
  88. > BTW, qed uses the block cursor concept... but with the well working UNDO >
  89. key, you'll not lose anything.
  90.  
  91. BTW, this is wishful thinking! You'll recover with UNDO _only_ if you realize
  92. immediately that something was marked and subsequently deleted. I have had the
  93. following happen in Windows big-block handling: accidental select block (click)
  94. or selected block scrolled off-screen and forgotten, type something looking at
  95. manuscript, and only much later realize that what I had typed had come at the
  96. wrong position, deleting a chunk of earlier text. (Ever wonder at the ubiquious
  97. occurance of mangled
  98. paragraphs in newspaper columns?)
  99.  
  100. Anyway, I agree with a previous poster saying that choice of block handling
  101. should be left to the application (since GEM doesn't impose global big-block in
  102. system dialogs), even though I originally brought up block handling in a
  103. question whether we needed to consider big/small blocks with regards to how
  104. certain shortcuts were chosen.
  105.  
  106.  
  107.  (illegible signature) Bo Leuf
  108.  - Email: bo.leuf@daggskim.ct.se
  109.  
  110.  
  111.  
  112.  
  113.